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Problem 

CPS  engineering  combines  diverse  model-based  analyses 
from  various  engineering  domains.  Differences  in  do¬ 
main  abstractions  lead  to  integration  issues: 

•  If  an  assumption  of  an  analysis  are  violated  by  anoth¬ 
er,  the  outputs  of  the  former  may  be  invalid. 

•  Specification  of  such  implicit  assumptions  and  detec¬ 
tion  of  their  violation  is  left  to  human  designers,  who 
are  often  unable  to  cope  with  complexity. 

•  Analysis  integration  problems  discovered  late  in  devel¬ 
opment  lead  to  expensive  changes  to  the  system. 


Hence  the  research  question: 

•  How  to  specify  analysis  compositions  and  verify  their 
correctness? 


Example  System 

Consider  an  autonomous  aircraft  as  an  example  CPS.  It 
operates  data  with  different  classes  of  security,  from 
normal  to  top  secret  (ThSecCl).  Periodic  threads  (T)  ex¬ 
ecute  on  several  processors  (C).  The  aircraft  is  powered 
with  multi-cell  reconfigurable  batteries  (B).  The  system’s 
architecture  shown  below  is  specified  in  AADL. 


A  battery  has  a  matrix  of  cells,  and  each  ceU  has  a  cur¬ 
rent  level  of  charge.  A  battery  scheduler  determines  par¬ 
allel  and  sequential  connections  between  groups  of  cells 
in  order  to  satisfy  voltage  and  current  output  require¬ 
ments. 


Thermally,  each  cell  exchanges  heat  with  its  neighboring 
cells  {thermal  neighbors,  TN)  through  an  electrical  connect¬ 
or,  affecting  the  risk  of  a  thermal  runaway. 
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Example  Analyses 


Verification  Domains 


A  verification  domain  a  —  ( cA,  S,  {R,  T,  [[|a)  formalizes 

domain-specific  constructs  for  several  related  analyses. 

•  c/l  —  a  set  of  sorts,  comprised  of  system  elements  and 

standard  sorts.  E.g.,  integers  H,  threads  T,  or  scheduling 
policies  SchedPol. 

•  S  —  a  set  of  static  functions  that  encode  design-time 
properties.  E.g.,  thread  period  Per,  thread-to-CPU  bind¬ 
ing  CPUBind,  and  system-wide  Voltage. 

.R-  -  a  set  of  runtime  functions  that  encode  dynamic 
properties.  E.g.,  preemption  relation  canPrmpt(ti,  t2) 
and  number  of  cells  in  a  battery  b  with  i  thermal  neigh¬ 
bors  TN  (b,  i) . 

•  T  —  execution  semantics  of  a  —  a  set  of  sequences  of 
assignments  to  R.  We  use  Promela  programs  to  imple¬ 
ment  the  semantics. 


[]a  —  a  domain  interpretation  of  c/Z,  S,  and  T. 

E.g.,  ISchedPolla  =  {RMS,  DMS,  EDF}. 


Formally,  an  AADL  architectural  model  m  is  an  interpre¬ 
tation  [[|m  of  c/Z,  S,  and  T.  E.g.,  [[Tim  =  {  SensorSample, 

Ctrh,  Ctrb  },  |[CPUBind]m  =  {  (Ctrh,  CPUi),  (Ctrb, 
CPU2),  ...)}. 


Analysis  Contracts 

Each  analysis  is  assigned  a  contract —  a  tuple  (I,  O,  A,  G). 

•  Inputs  I Q  cA  \J  S  declare  elements  that  the  analysis 
reads. 

•  Outputs  O  Q  cA  \J  S  declare  elements  that  the  analysis 
writes. 

•  Assumptions  A  QTa  are  logical  statements  that  must 
be  satisfied  by  every  input  model  to  the  analysis:  m 

•  Guarantees  G  QTa  are  logical  statements  that  must  be 
satisfied  by  every  output  model  of  the  analysis:  m  ^  G. 


Assumption  and  guarantee  formulas  have  the  following 
syntax: 

To  V  vi...Vj*  (p  I  3  vi...Vj*  (p  I 
V  vi...Vj  •  (p  :  ij;  I  3  vi...Vj  •  (p  :  ij;, 

where  (p  is  a  predicate  logic  formula  over  c/?  U  (S’,  ij;  is  an 
LTL  formula  over  A.  \J  S  \J  R. 


Scheduling  verification  domain  asched 


Analysis  Ordering 

Correct  execution  of  analyses  requires  satisfaction  of  aU 
input-output  dependencies  for  each  analysis.  Formally, 
contract  Cl  depends  on  contract  Qif  C.I  Pi  Cj.O  ^  0. 

Am  ordering  <Ci...C„>  of  contracts  is  sound  if  and  only 
if  predecessors  are  not  dependent  on  successors: 

Vi  G  [1,  n]  •  Vj  G  [1,  i)  •  Cj.l  n  C.O  =  0. 

Consider  a  graph  with  vertices  being  contracts  and  edges 
being  contract  dependencies.  There  exists  a  sound  order¬ 
ing  of  contracts  if  and  only  if  the  graph  is  not  cyclic.  If 
it  is  not  cyclic,  any  topological  ordering  is  sound. 

Contract  Verification 

The  goal  of  contract  verification  is  to  decide  m  ^  To . 

For  purely  first-order  formulas  that  contain  only  (p,  we 
decide  satisfiability  via  SMT  solving.  An  SMT  program  is 
generated  based  on  A  and  S  mentioned  in  (p,  and  an 
SMT  solver  is  invoked  on  (p  (or  (p  for  existential  quan¬ 
tification).  A  universally  (existentially)  quantified  contract 
is  satisfied  if  and  only  if  UNSAT  (SAT)  is  returned. 


For  formulas  combining  predicate  formula  (p  and  LTL 
formula  ij;,  we  first  generate  an  SMT  program  for  (p  and 

find  all  valuations  of  vi...Vj  that  satisfy  (p.  For  each  such 
valuation  we  call  Spin  on  a  Promela  program  that  imple¬ 
ments  T  form  in  the  domain  of  ijj.  Formula  ij;  is  trans¬ 
formed  into  an  LTL  property  specification  in  Promela.  A 
universally  (existentially)  quantified  contract  is  satisfied  if 
and  only  if  the  LTL  property  holds  for  all  (at  least  one) 
valuations.  The  architecture  of  our  verification  tool  is 
shown  below: 


Experimental  Results 

Effectiveness:  we  have  been  able  to  detect  analysis  integra¬ 
tion  errors  and  verify  their  absence  for  each  analysis  in 
the  example. 

Scalability:  the  results  of  scalability  experiments  with  our 
implementations  of  7  are  shown  in  the  tables  below. 
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time* 

EDF  time* 

3 

0.01 

0.01 

4 

0.01 

0.52 

5 

0.07 

33.4 
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0.37 

2290.0 
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2.18 

memlim 
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memlim 
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time* 
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0.13 

0.15 

0.15 
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0.61 
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3.94 

16 

44 

31.4 

127 

20 

1060 

619 

memlim 

25 

memlim 

memlim 

memlim 

*  All  times  are  in  seconds. 
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